A conventional virtual machine manager (VMM) may run on a computer to present the abstraction of one or more VMs to other software. Each VM may function as a self-contained platform that runs its own software stack, including an operating system (OS) and applications, collectively this software stack is referred to as “guest software.” Guest software running on a VM expects to operate as if it were running on a dedicated computer. For example, the guest software expects to control various computer operations and have access to physical (i.e., hardware) resources during these operations. The physical resources may include processor-resident resources, such as control registers, resources that reside in memory, such as descriptor tables, and devices on the hosting hardware platform, such as IO devices. In a VM environment, the VMM has ultimate control over the hardware resources. In order to provide protection from and between VMs, the VMM typically intercepts and arbitrates all accesses to the hardware resources made by the guest software.
When a plurality of VMs attempts to access an IO resource, the plurality of VMs must compete for the IO resource, with the VMM arbitrating the accesses to the resource. In the past, VMMs granted access to a shared resource without regard to the latency requirements of the guest software. This approach effectively failed to schedule requests to access IO resources based upon the requirements of the guest software. For example, guest software having no quality of service requirement may be granted access to an IO resource ahead of guest software having a high quality of service requirement because of the timing of the requests made. In some instances, the result of this scheduling would cause guest software to fail to meet its timing requirements and would adversely affect its performance.
Thus, what is needed is an efficient and effective method and apparatus for scheduling VM access to IO resources.